-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log a warning when documents of unknown types are detected during migration #105213
Log a warning when documents of unknown types are detected during migration #105213
Conversation
...stateP, | ||
controlState: 'FATAL', | ||
reason: extractUnknownDocFailureReason(res.left.unknownDocs, stateP.sourceIndex.value), | ||
...nextState, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's debatable whether or not this should be a left or a right result. I opted to keep it left since we just going to change this again to a failure case in the master
branch for 8.0. We also don't have an analog for isRightTypeof
and it didn't seem worth adding for just this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say right
. we don't need a isRightTypeof
, as in right
case, we would just returns the unknownDocs
array in the right
return of checkForUnknownDocs
(and just append the log if unknownDocs.length>0
). But that's not that important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, when I was working with Rudolf I understood that left
results were those that ultimately led to an error state (i.e. migrations would fail). right
results are all those that carry on with the 'happy path' through the migration algorithm. That being said, I also got the feeling were were trying to avoid error handling in the control flow which is kinda what we end up doing in a few cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback, pushed a commit to switch to Either.right
👍
Pinging @elastic/kibana-core (Team:Core) |
...stateP, | ||
controlState: 'FATAL', | ||
reason: extractUnknownDocFailureReason(res.left.unknownDocs, stateP.sourceIndex.value), | ||
...nextState, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say right
. we don't need a isRightTypeof
, as in right
case, we would just returns the unknownDocs
array in the right
return of checkForUnknownDocs
(and just append the log if unknownDocs.length>0
). But that's not that important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
...stateP, | ||
controlState: 'FATAL', | ||
reason: extractUnknownDocFailureReason(res.left.unknownDocs, stateP.sourceIndex.value), | ||
...nextState, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, when I was working with Rudolf I understood that left
results were those that ultimately led to an error state (i.e. migrations would fail). right
results are all those that carry on with the 'happy path' through the migration algorithm. That being said, I also got the feeling were were trying to avoid error handling in the control flow which is kinda what we end up doing in a few cases.
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
…-png-pdf-report-type * 'master' of github.com:elastic/kibana: (292 commits) bring back KQL autocomplete in timeline + fix last updated (elastic#105380) [Maps] Change TOC pop-up wording to reflect filter change, not search bar change (elastic#105163) Updating urls to upstream elastic repo (elastic#105250) [Maps] Move new vector layer wizard card down (elastic#104797) Exclude registering the cases feature if not enabled (elastic#105292) [Uptime] Alerts - Monitor status alert - check monitor status by monitor.timespan (elastic#104541) updated UI copy (elastic#105184) Log a warning when documents of unknown types are detected during migration (elastic#105213) [Logs UI] Register log threshold rule as lifecycle rule (elastic#104341) [Ingest pipelines] add network direction processor (elastic#103436) [Console] Autocomplete definitions (manual backport) (elastic#105086) [Security Solution] User can make Exceptions for Memory protection alerts (elastic#102196) [Lens] Formula: add validation for multiple field/metrics (elastic#104092) Removing async from file upload and data visualizer plugins start lifecycle (elastic#105197) Fix error when validating the form with non blocking validations (elastic#103629) [ML] Fix "View by" swim lane with applied filter and sorting by score (elastic#105217) Update dependency @elastic/charts to v32 (elastic#104625) [CTI] shortens large numbers on Dashboard Link Panel (elastic#105269) [Security Solution][Endpoint][Host Isolation] Fixes bug to remove excess host metadata status toasts on non user initiated errors (elastic#105331) [Cases] Fix pushing alerts count on every push to external service (elastic#105030) ... # Conflicts: # x-pack/plugins/reporting/common/types.ts
…118300) * manually revert #105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]>
…lastic#118300) * manually revert elastic#105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]>
…118300) (#118690) * manually revert #105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Pierre Gayvallet <[email protected]>
…lastic#118300) * manually revert elastic#105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]>
…118300) * manually revert #105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]>
…lastic#118300) * manually revert elastic#105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]>
…lastic#118300) * manually revert elastic#105213 * enabled xpack to register types for some IT tests * fiz doc size Co-authored-by: Kibana Machine <[email protected]>
Summary
Fixes #104690
This updates our handling of unknown types during Saved Object migrations for the 7.x series. See the rationale and decision in #104690 (comment). The following changes were required to support this:
migrationVersion
field would fail the migration. Note that this will need to be changed in order to support the core migrations for ID rewriting in 8.0.Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
.kibana
index and retrying the upgrade.For maintainers